Add AI binding support for pi by Maximo-Guk · Pull Request #123 · cloudflare/cloudflare-os

Maximo-Guk · 2026-08-10T15:42:41Z

Why?
We want to enable users to use AI gateway without needing to provide an API token ( which puts them at risk of credential expiry, rotation, etc ) and makes them need to visit the dashboard just to provision a token during the deploy flow.

How?

Workers AI Gateway can now be accessed over the AI binding!

AI.fetch(https://workers-binding.ai/ai-gateway/gateways/platform-gateway/*)

How was this tested?

You can test it with the updated deploy flow which is based off this branches head https://gadgets-deploy.gadgets-staging.workers.dev/deploy ( notice you don't need to provision an api token ), and also locally.

kentonv · 2026-08-11T23:48:33Z

Looks like upstream PR was merged, shall we update to use that?

Maximo-Guk · 2026-08-12T02:04:19Z

Just waiting on a PI release before we can use the upstreamed changes, I'll put up a PR to update once it gets released.

The vendored transport changes in this PR are identical to what got merged in to PI, I would like to get this out so we can start battle testing what we upstreamed in to PI.

Maximo-Guk · 2026-08-13T20:08:19Z

Drafting this for the time being as I work through on updating the PI implementation to be smarter & more efficient

ask-bonk · 2026-08-18T02:30:42Z

github run

ask-bonk · 2026-08-18T02:30:45Z

@Maximo-Guk Bonk workflow failed. Check the logs for details.

View workflow run · To retry, trigger Bonk again.

github-actions · 2026-08-18T02:32:01Z

Preview: `pr123-maximo-add-ai-3d199549`

https://pr123-maximo-add-ai-3d199549-router.cloudflare-os-previews.workers.dev

Dashboard · deleted when this PR closes

Maximo-Guk · 2026-08-18T02:41:58Z

bonk break glass

devin-ai-integration

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 1 additional finding.

…E_BINDING opt-out

…ays rides the gateway The WAI knobs existed because Workers AI originally ran on the account-local WORKERS_AI binding, which can only name same-account gateways; a cross-account CF_AI_GATEWAY (the internal production shape) therefore needed an escape hatch. Workers AI has since moved to ordinary gateway routes (.../{account}/{gateway}/workers-ai/v1), which work cross-account over HTTPS+token exactly like anthropic/openai -- so the escape hatch no longer pays for its config surface.

Binding-routed gateway traffic went through gateway().run(), the universal endpoint's [{provider, endpoint, headers, query}] envelope, which a vendored shim built by splicing the request body into a JSON string. The gateway also serves its provider-native passthrough over the AI binding at /ai-gateway/gateways/{gateway}/{provider}/... -- the HTTPS path minus the account id, since the binding channel carries identity -- and that route accepts exactly the requests pi's API impls already produce. So there is nothing left to translate. Binding-routed models take the binding host as their gateway root and pi's fetch option is the binding's own fetch, unwrapped; the envelope, the splice, the JSON-object scanner and the whole vendored ai-gateway-binding-fetch module go away. Method, headers, query string and the body stream ride through untouched, so multi-MB prompt bodies are never copied in the isolate. Google keeps its HTTPS root automatically: `binding` is resolved per provider, and bindingFor() returns undefined for google (its adapter can't take a custom fetch). cf-aig-authorization now reaches the gateway, which recognizes the pre-authentication sentinel and strips it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Trim and lowercase the value once on each side, so a stray " False " opts out instead of reading as unset and silently picking the other transport. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Maximo-Guk · 2026-08-18T20:57:38Z

bonk break glass

… Workers AI isn't recommended ( breaks toMarkDown() )